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Beschrefbung 

Strukturierung, Speicherung und Verarbeitung von Daten gemali 
einem generischen Objektmodell 

Die Erfindung betrifft ein System sowie ein Verfahren zur 
Strukturierung, Speicherung und Verarbeitung von Daten. 

Oblicherweise werden Sof tware-Applikationen 
unterschiedlichster Art zur Losung technischer 
Auf gabenstellungen, z, B. dem Engineering eines 
Automatisierungssystem, eingesetzt, wobei jede dieser 
Sof tware-Applikationen einerseits spezifische technische 
Aufgaben erfiillt, andererseits mit anderen Software- 
Applikationen zur Losung einer technischen Aufgabe 
zusammenwirkt . Letzteres impliziert, dass die Sof tware- 
Applikationen uber Schnittstellen Daten austauschen. Die 
Schnittstellen, welche die einzelnen Sof tware-Applikationen 
bieten, sowie die daruber transportierten Daten, sind meist 
sehr heterogen und proprietor. In der Regel werden die zu 
transportierenden Daten jeweils fur den individuellen 
Austauschbedarf strukturiert . Ober verschiedene Sof tware- 
Applikationen hinweg fuhrt das jedoch zu inkompatiblen 
Austauschstrukturen. 

Der Erfindung liegt die Aufgabe zugrunde, den Datenaustausch 
zwischen verschiedenen Sof tware-Applikationen zu 
vereinfachen. 

Diese Aufgabe wird durch ein System zur Strukturierung, 
Speicherung und Verarbeitung von Daten gemafi einem 
generischen Objektmodell- gelost, wobei das Objektmodell 
mindestens ein erstes Element aufweist, welches einem Typ 
Objekt entspricht, wobei der Typ Objekt folgende Merkmale 
aufweist : 

- eine eindeutige Bezeichnung der Identitat des Objekts zur 
absoluten Ref erenzierung des Objekts, 
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- einen" logischen Namen zur Benennung des Objekts und 
mindestens eine Verkniipfung mit einem zweiten Element , 
welches einem Typ Feature entspricht, wobei der Typ 
Feature folgende Merkmale aufweist: 

5 - einen im Bezug auf das jeweilige verkntipfte Objekt 

eindeutigen Namen und 
die Moglichkeit der Verkniipfung mit weiteren Elementen vom 
Typ Objekt , mit weiteren Elementen vom Typ Feature und mit 
Daten . 

Diese Aufgabe wird durch ein Verfahren zur Strukturierung, 
Speicherung und Verarbeitung von Daten gemali einem 
generischen Objektmodell gelost, wobei das Objektmodell 
mindestens ein erstes Element aufweist, welches einem Typ 
15 Objekt entspricht, wobei der Typ Objekt folgende Merkmale 
aufweist : 

- eine eindeutige Bezeichnung der Identitat des Objekts zur 
absoluten Ref erenzierung des Objekts, 

einen logischen Namen zur Benennung des Objekts und 
20 - mindestens eine Verkniipfung mit einem zweiten Element, 
welches einem Typ Feature entspricht, wobei der Typ 
Feature folgende Merkmale aufweist: 

- einen im Bezug auf das jeweilige verkntipfte Objekt 
eindeutigen Namen und 
die Moglichkeit der Verkniipfung mit weiteren Elementen vom 
Typ Objekt, mit weiteren Elementen vom Typ Feature und mit 
Daten. 

Die Erfindung beruht auf der Idee, komplexe, vorzugsweise 
30 hierarchisch aufgebaute Datenmengen mit einem einheitlichen 
Objektmodell zu beschreiben und zu strukturieren . Alle 
Elemente des Typs Objekt haben die gleiche Grundstruktur , 
sind jedoch in unterschiedlichen Granularitatsstuf en 
einsetzbar. Die Struktur eines iibergeordneten Elements vom 
35 Typ Objekt findet sich also in der Struktur eines 

untergeordneten Elements vom Typ Objekt wieder. Das gesamte 
Objektmodell besitzt somit bis zur untersten Ebene eine 
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annahernd fraktale Struktur. Die Strukturierung der 
Datenmenge gelingt durch Replikation weniger Grundmuster und 
Grundstrukturen. Durch die Verwendung dieses 
Darstellungsprinzips (Objekt, Feature, etc.) kann erreicht 
werden, dass alle damit modellierten Datenbestande gemeinsame 
Grundstrukturen beinhalten, mit denen ein universelles 
Verstandnis moglich ist. Alle Elemente stellen die Struktur- 
Information eines Datenbestands dar. Applikationen konnen so 
auf einheitliche Weise auf die Daten zugreifen bzw. in den 
Objektgeflechten navigieren. Ferner konnen beliebige, heute 
noch nicht bekannte Abbildungsanf orderungen erfullt werden, 
die dann auch wieder in dieses grundsatzliche Verstandnis der 
Einheitlichkeit einflieilen und von anderen Applikationen 
verstanden werden. Applikationen die sich diesem 
einheitlichen Format zukunftig anpassen, geniefien dann 
automatisch auch die Kompatibilitat mit alien vorherigen. 

Die Bezeichnung der Identitat eines Objektes wird nach der 
Erzeugung nie mehr geandert, insbesondere bleibt sie bestehen 
beim Verschieben des Objekts innerhalb eines Datenbestandes 
oder dem Einfugen des Objektes in andere Datenbestande. Die 
Identitat dient zur eindeutigen Identif izierung eines 
Objekts, d. h. uber die Identitat kann ein Objekt absolut, 
also ohne Bezug zu seiner Umwelt bzw. seinem Kontext, 
referenziert werden. 

Neben einer Identitat hat jedes Objekt einen logischen Namen. 
Der Name kann im Gegensatz zur Identitat geandert werden und 
muss auch nicht global eindeutig sein. Wenn jedoch 
Eindeutigkeit unter den Namen der Objekte in jedem Feature 
herrscht, dann konnen diese zur Bildung sogenannter Pfad- 
Referenzen (Referenzen eines Objekts im Bezug auf seine 
Umwelt) dienen. 

Elemente des Typs Feature bilden die Substruktur der Objekte. 
Sie gruppieren z. B. Parameter, Referenzen, Subobjekte, 
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Connect oren und Connections des Objekts und kSnnen auch 
selbst wieder iiber Features strukturiert werden. 

Gemali einer vorteilhaf ten Ausgestaltung der Erfindung weist 
der Typ Objekt als weitere Merkmale eine Kennzeichnung des 
Objektstyps und eine Kennzeichnung einer Version des Objekts 
auf. Dies ist insbesondere vorteilhaft zur Strukturierung von 
komplexen, zeitlich variablen Datenbestanden. 

Eine weiter verbesserte Strukturierung der Daten lasst sich 
erreichen, wenn die durch ein Element vom Typ Feature 
verknupften und gruppierten Elemente eine logisch 
zusammengehorige Teilmenge aller Elemente eines Objekts 
bilden. Grundlage der Gruppierung konnen zum einen eine 
logische Zusammengehorigkeit der Elemente des Objekts zu 
einer bestimmten "Sicht" (z. B. HMI, Hardware, Software) auf 
das Objekt sein. Mit dieser Unterteilung konnen die 
jeweiligen Applikationen leichter jene Objekt-Daten lesen, 
die sie interessieren. Zum anderen konnen Features zur 
Erweiterung von bestehenden Objekten urn spezifische weitere 
Objektinf ormationen verwendet werden , die zum Objekt 
hinzugefugt werden sollen und evtl. nur fur bestimmte 
Applikationen .von Interesse sind, Dieser Weg kann 
sinnvollerweise im Gegensatz zur Erweiterung durch Ableitung 
gewahlt werden, urn Produkte, die mit bestehenden Typen 
artieiten, nicht inkompatibel werden zu lassen. Durch die 
Erweiterung iiber neue Features muss auf bestehende 
Applikationen keine Rucksicht genommen werden. 

Des Weiteren konnen die Objekte iiber Features auch weitere 
(Su£~) Objekte und Referenzen zu anderen Objekten enthalten. 
Uber die Aggregation entsteht so ein Baum aus Objekten, wobei 
durch die Referenzen Querbezuge zwischen den Elementen dieses 
Baums dargestellt werden konnen. Vorteilhaf terweise werden 
keine Rollen von Objekten explizit spezif iziert . Die Rollen 
werden implizit durch die Position eines Objekts im 
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Verhaltnis zu anderen Objekten dargestellt, beziehungsweise 
durch die Referenzen von und zu anderen Objekten ausgedriickt. 

Wird das Objektmodell durch eine erweiterbare 
Kennzeichnungssprache beschrieben (z. B. XML = Extensible 
Markup Language) , so erreicht man neben Einheitlichkeit und 
Erweiterbarkeit auch systematische Validierbarkeit . 

Ublicherweise bilden Datenbestande, welche beim Engineering 
von Automat is ierungssystemen Verwendung finden, umfangreiche 
und komplexe hierarchische Strukturen. Urn deren strukturellen 
Inhalt einheitlich und transparent fur verschiedene 
beteiligte Applikationen zur Verfugung zu stellen, wird die 
Verwendung des erf indungsgemafoen Systems bzw. Verfahrens zum 
Engineering einer Automatisierungslosung vorgeschlagen . 

Nachfolgend wird die Erfindung ahhand der in den Figuren 
dargestellten Ausf uhrungsbeispiele naher beschrieben und 
erlautert . 

Es zeigen: 

FIG 1 die Grundidee des Objektmodells in Form eines UML- 



In FIG 1 wird die Grundidee des Objektmodells 10 in Form 
eines UML-Diagramm dargestellt. UML (= Unified Modeling 
Language) ist eine durch die Object Management Group (OMG) 
standardisierte graphische Sprache zur Beschreibung 
objektorientierter Modelle. Im Mittelpunkt des Objektmodells 
10 steht der Typ Objekt 100. Im Ausf Uhrungsbeispiel besitzt 
jedes Objekt 100 die Attribute ID 2, OType 5, Version 4 und 
Name 3. Die ID 2 ist hierbei eine eindeutige Bezeichnung, die 
sich nie andert. Die ID 2 kann zum Beispiel eine GUID (= 



Diagramms und 



FIG 2 



ein System zum Engineering einer 
Automatisierungslosung . 
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Globally Unique Identifier) sein. Sie dient zur eindeutigen 
Identif izierung des Objektes 100, d. h. uber die ID 2 kann 
das Objekt 100 absolut, also ohne Bezug zu seiner Umwelt bzw. 
seinem Kontext, referenziert werden. Jedem Objekt 100 wird 
ein Name 3 zugeordnet. Ober den Namen 3 kann das Objekt 100 
ebenfalls referenziert werden. 

Wie im Diagramm von FIG 1 zu sehen, bilden Features 20 die 
Substruktur der Objekte 100. Sie gruppieren die Parameter 30, 
Referenzen 60, Sub-Ob jekte 100, Connectoren 4 0 und 
Connections 50 des Objekts 100 und konnen auch selbst wiede.r 
uber Features 20 strukturiert werden. Die Verknupfung zum 
SubObjekt 100 ist im UML- Diagramm von FIG 1 mit dem 
Bezugszeichen 70 gekennzeichnet , das SubObjekt 100 erhalt 
jedoch das gleiche Bezugszeichen wie das oben erwahnte Objekt 
100, da es die gleiche Struktur aufweist. Grundlage der 
Gruppierung sind zum einen die logische Zusammengehorigkeit 
der Bestandteile des Objekts 100 zu einer bestimmten "Sicht" 
(z.B. HMI, Hardware, Software) auf das Objekt 100. Mit dieser 
Unterteilung konnen die jeweiligen Tools leichter jene 
Objekt-Daten lesen, die sie interessieren. 

Zum anderen bilden Features 20 die Einheit der Erweiterung 
von Objekten 100 urn produktspezif ische Bestandteile. Features 
20 konnen somit zur Erweiterung von bestehenden Objekttypen 
urn spezifische weitere Objektinf ormationen verwendet werden, 
die zum Objekt 100 hinzugefugt werden sollen und evtl. nur 
fur bestimmte Applikationen von Interesse sind. Dieser Weg 
wurde im Gegensatz zur Ableitung gewahlt, um Produkte, die 
mit bestehenden Typen arbeiten, nicht inkompatibel werden zu 
lassen. Wenn ein Objekttyp um Daten eines anderen Produkts 
erweitert werden soil, so wird ein neues Feature 20 
definiert, das dann zu dem bestehenden Objekt 100 dazugefugt 
wird. Die Definition des ursprunglichen Objekttyps bleibt 
dabei bestehen, damit die Tools, die mit dem bisherigen 
Objekttyp arbeiten, nicht beeintrachtigt werden. Durch die 
Erweiterung uber Features 20 muss auf bestehende 
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Applikationen keine Riicksicht genornmen werden. Features 20, 
die einen im Bezug auf das jeweilige Objekt 100 eindeutigen 
Namen 21 tragen, haben jeweils 1 zu n - Beziehungen zu 
Parametern 30, Connectoren 40 und Connections 50. Des 
Weiteren konnen die Objekte 100 uber Features 20 auch Sub- 
Objekte 100 aggregieren und Referenzen 60/Relationen zu 
anderen Objekten 100 enthalten. Ober die Aggregation entsteht 
ein Baum aus Objekten 100. Durch die Referenzen 60 konnen 
Querbeziige zwischen den Elementen dieses Baums dargestellt 
werden. Die Parameter 30, Connectoren 40 und Connections 50 
stellen bildlich gesprochen das Laub des Baumes, also im 
Bezug auf die zu modellierenden Datenbestande die 
eigent lichen Daten dar. Features 20 konnen selbst wieder 
Features 20 enthalten. Objekte, Features und Referenzen 
stellen die Struktur-Inf ormation eines Datenbestandes dar. 

Die Identitat ID 2 eines Objektes 100 wird nach der Erzeugung 
nie mehr geandert. Insbesondere bleibt sie bestehen beim 
Verschieben des Objekts 100 innerhalb eines Datenbestandes 
und beim Einfugen des Objektes 100 in andere Bestande. Die ID 
2 dient als absolute Referenz auf ein Objekt 100. D. h. uber 
die ID 2 kann ein Objekt 100 absolut, also ohne Bezug zu 
seiner Umwelt/zu seinem Kontext referenziert werden. Neben 
einer ID 2 hat jedes Objekt 100 einen (logischen) Namen 3. 
Der Name 3 kann im Gegensatz zur ID 2 geandert werden und 
muss auch nicht global eindeutig sein. Wenn jedoch 
Eindeutigkeit unter den Namen 2 der SubObjekte 100 in jedem 
Feature 20 herrscht, dann konnen diese zur Bildung 
sogenannter Pf ad-Ref erenzen (Referenzen, die ein Objekt 100 
im Bezug auf seine Umwelt ref erenzieren) dienen. 

Es werden keine Rollen von Objekten 100 explizit 
spezif iziert . Die Rollen werden vielmehr implizit durch die 
Position eines Objekts 100 im Verhaltnis zu anderen Objekten 
100 dargestellt, beziehungsweise sie werden durch die 
Referenzen 60 von und zu anderen Objekten 100 ausgedrtickt. 
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Durch die Verwendung dieses Darstellungsprinzips (Objekt 100, 
Feature 20, etc,) kann erreicht werden, dass alle damit 
modellierten Datenbestande gemeinsame Grundstrukturen 
beinhalten, mit denen ein universelles Verstandnis moglich 
ist, sprich Applikationen auf einheitliche Weise auf die 
Inhalte zugreifen bzw. in den Objektgef lechten navigieren 
konnen. Ferner konnen beliebige, heute noch nicht bekannte 
Abbildungsanf orderungen erfullt werden, die dann auch wieder 
in dieses grundsatzliche Verstandnis der Einheitlichkeit 
einflieften, und von anderen Applikationen verstanden werden. 
Applikationen die sich diesem einheitlichen Format zukiinftig 
anpassen, geniefien dann automatisch auch die Kompatibilitat 
mit alien vorherigen. 

Wenn man diesen Gedanken in Schemas der Metasprache XML 
(=Extensible Markup Language) niederlegt, so erreicht man 
neben Einheitlichkeit und Erweiterbarkeit auch systematische 
Validierbarkeit . Das obige Objektmodell 10 sei im Folgenden 
anhand einer Darstellung als Schema in XML gezeigt: 

<xsd: complexType name="Ob j ectT"> 
<xsd : sequence> 

<xsd: element name=" Features " type="FeaturesT" minOccurs="0"/> 
</xsd: sequence> 

<xsd: attribute name="ID" type="IdT" use«"required"/> 
<xsd: attribute name="Name" type="xsd : string" use="required"/> 
<xsd: attribute name=" Version" type="VersionT" use="optional"/> 
<xsd: attribute name="Type" type="xsd : QName" use="optional"/> 
</xsd: complexType> 

<xsd: complexType name="FeatureT" /> 
<xsd: complexContent> 
<xsd: sequence> 

<xsd:element ref="Parameter " minOccurs="0 f V> 
<xsd:element ref="Ref erence" minOccurs="0" /> 
<xsd: element ref="Object" minOccurs= s "0" /> 
</xsd: sequence> 
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<xsd: attribute name="Name" type="xsd: string" use="required"/> 
</xsd: complexContent> 
</xsd: coraplexType> 

<xsd:complexType name="ParameterT"> 

<xsd: annotation> 

<xsd: documentation>Base type for all DIA-X parameters that 
are used within features of objects</xsd: document at ion> 

</xsd: annotation> 

<xsd: attribute name="MustUnderstand" type="xsd: boolean" 
use="optional" def ault="f alse" /> 

<xsd: attribute name="Name" type="xsd: string" use="optional" /> 
</xsd: complexType> 

Die der Erfindung zugrundeliegende Idee wird anhand eines 
weiteren Ausf uhrungsbeispiels naher erlautert. Darzustellen 
sei ein Symbol, wie diese z. B. in der Automat is ierungs- 
technik ublich sind. So ,ein Symbol enthalt neben seinem Namen 
noch einen Typ, eine Richtung und einen Wert. Das zu zeigende 
Beispiel-Symbol sei dieses: 

S7_AO_Niveau EO . 3 

Wobei M S7_A0_Niveau" der Name des Symbols ist. Typ und 
Richtung sind zusammen mit dem Wert in der Bezelichnung E0.3 
in der Weise verschlusselt, das "E" die (deutschsprachige) 
Richtungsbezeichnung fur "Eingang" bedeutet, und in der 
Punkt-Darstellung sich die Adressierung eines Bits innerhalb 
eines Wortes ausdruckt. Das Beispiel-Symbol wurde gemali dem 
obigen Objektmodell 10 wie folgt dargestellt werden, und auch 
validierbar sein, wenn man das oben gezeigte allgemeine 
Schema noch mit den anschlieflend gezeigten symbol- 
spezifischen Verf einerungen versieht. Eine Instanz des 
Beispiel-Symbols * S7_AO_Niveau" ist als XML-Schema 
f olgendermalien definiert: 
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<base : Symbol ID=" { 5ED19706-3840-4daO-ADD2- 
27491C0A58BB} "Name="S7_AO_Niveau"> 
<base : Address Feature> 

<base:SymbolAddress Direction="In" AddressType="Bit" Value="3.0" /> 
5 </base : Address Feature> 

</base : Symbol> 

Im Folgenden werden die genannten symbol-spezif ischen 
Verf einerungen beschrieben, mit deren Hilfe ein so 
10 beschriebenes Symbol validierbar wird. Als Erstes ist vom 
allgemeinen Typ "Objekt" ein symbol-spezif ischer Objekttyp 
(hier genannt " SymbolT" ) abzuleiten, Dieser enthalt wie oben 
erklart auch ein Feature (da er ja abgeleitet ist) , namlich 
wiederum ein symbol-spezif isches Feature- Es sei 
15 w SymbolAdressFeatureT" genannt. 

<xsd: element name=" Symbol" type=" SymbolT" 
substitut ionGroup="diax : Obj ect "/> 

20 <xsd: complexType name= "SymbolT "> 
<xsd : complexContent> 

<xsd : extension base="diax : Obj ectT "> 
<xsd : sequence> 

<xsd: element name=* "Address Feature" 
type="SymbolAddressFeatureT"/> 
</xsd: sequence> 
</xsd: extension> 
</xsd: complexContent> 
</xsd : complexType> 



Dieses symbol-spezif ische Feature (genannt 

"SymbolAddressFeatureT" - wobei "T" fur Typ steht) enthalt 
gemafi obigem Basis-Objekt einen Parameter, namlich wiederum 
einen symbol-spezif ischen, der x> SymbolAddressT" heifit: 



35 



Feature SymbolAddressFeatureT 
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<xsd: complexType name="SymbolAddressFeatureT"> 
<xsd: complexContent> 

<xsd: extension base="diax : FeatureT"> 
<xsd : sequence> 

5 <xsd: element narae=" Symbol Address" 

type="SymbolAddressT"./> 

</xsd: sequence> 
</xsd: extension> 
</xsd: complexContent> 
10 </xsd: complexType> 

Der symbol-spezifische Parameter xx SymbolAddressT" wird im 
Folgenden definiert. Er enthalt die restlichen Inf prmationen 
Datentyp, Richtung, Wert. 



15 



Parameter SymbolAddressT 



<xsd: complexType name="SymbolAddressT"> 
<xsd: complexContent> 
20 <xsd: extension base="diax : ParameterT"> 

<xsd: attribute name="AddressType" type="AddressTypeEnumT" 
use=" required" /> 

<xsd: attribute name="Direction" type=" Direct ionEnumT" 
use=" required" /> 

<xsd: attribute name="Value" type="xsd: string" 
use="required" /> 

</xsd : extension> 
</xsd : complexContent> 
</xsd : complexType> 

30 

Mit weiteren Spezif ikationen sind die im Adress-Parameter 
verwendeten Attribute ,Typ' und , Richtung' definiert. Der 
"Wert" ist letztlich nur ein xsd: string ohne Einschrankungen. 
Damit gentigt das obige Beispiel-Symbol dem generischen Grund- 
35 Objektmodell 10 und ist voll validierbar festgelegt. 
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Oblichefweise sind Datenbestande 210, wie sie im Engineering 
220 von Automat is ierungssystemen 230 vorkommen, als 
umfangreiche, komplexe hierarchische Strukturen beschaffen. 
Urn deren strukturellen Inhalt einheitlich, und transparent 
fur andere zu machen, kann ein einfaches erf indungsgemafies 
Objektmodell 10 als zentrales, generisches Grundelement der 
Darstellung definiert werden. Das sei im Folgenden am 
Beispiel eines Hardware-Pro jekts 200 mit seinem strukturellen 
Aufbau demonstriert (siehe FIG 2). Das mit "Projekt" 200 
benannte hierarchische Gefuge beinhalte eine Verarbeitungs- 
station 201, welche als "SI 300" bezeichnet wird. Diese 
enthalte auf einem "Rack UR" 202 eine "CPU 315" 203, die 
unter vielem anderen in ihrem Symbol-Container das Symbol 
"S7_AO_Niveau" enthalt. Zur validierbaren Darstellung dieser 
Strukturen sind naturlich wiederum spezifische Verf einerungen- 
der Standard Schemas notwendig (zum Beispiel das 
StructuralFeature, das den Aufbau eines Objektes beschreibt) , 
auf deren Darstellung hier jedoch verzichtet wird. Hier sei 
der Hinweis genug, dass derer beliebig viele durch 
entsprechende Ableitung erstellt werden konnen, wodurch alle 
dargestellten Daten dann auch systematisch validierbar sind, 

<base: Project ID=" {3E397603-9E8C-46EC-8B41-10A60FAA3B17 } " Name="Project "> 
<base : StructuralFeature> 
<base: Device ID=" {EEAD7EA6-2F73-4 6D8-BCF2-2DAC712CF813 } " Name="S7300"> 
<base : StructuralFeature> 

<base: Device ID=" { E378890F-DEA9-41EF-8C35-6EEF76FD748B} " Name= ,, UR"> 
<base : StructuralFeature> 
<base: Device ID=" { 85852272-12E2-4D4 . . . } " Name="CPU315"> 
<base : Sof twareFeature> 
<base: Symbol ID= M { 85F306C6-4 12...} " Name= ,, S7_AO_Niveau"> 
<base : AddressFeat ure> 

<base:SymbolAddress Direction= f, In" AddressType="Bit " 
Value= w 0.3"/> 

</base : Address Feature> 
</base : Syrabol> 
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Zusammenf assend betrifft die Erfindung somit ein System sowie 
ein Verfahren zur Strukturierung, Speicherung und 
Verarbeitung von Daten. Der Datenaustausch zwischen 
verschiedenen Sof tware-Applikationen wird vereinfacht durch 
5 die Strukturierung, Speicherung und Verarbeitung gemaii einem 
generischen Objektmodell 10, wobei das Objektmodell 10 
mindestens ein erstes Element aufweist, welches einem Typ 
Objekt 100 entspricht, wobei der Typ Objekt 100 folgende 
Merkmale aufweist: 
10 - eine eindeutige Bezeichnung 2 der Identitat des Objekts 
100 zur absoluten Referenzierung des Objekts 100, 

- einen logischen Namen 3 zur Benennung des Objekts 100 und 

- mindestens eine Verknupfung 6 mit einem zweiten Element, 
welches einem Typ Feature 20 entspricht, wobei der Typ 

15 Feature 20 folgende Merkmale aufweist: 

- einen im Bezug auf das jeweilige verknupfte Objekt 100 
eindeutigen Namen 21 und 

die Moglichkeit der Verknupfung mit weiteren Elementen 
vom Typ Objekt 100, mit weiteren Elementen vom Typ Feature 20 
20 und rait Daten 30, 40, 50. 
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Patentanspruche 

1. System zur Strulcturierung, Speicherung und Verarbeitung 
von Daten gemali einem generischen Objektmodell (10), wobei 
das Objektmodell (10) mindestens ein erstes Element aufweist, 
welches einem Typ Objekt (100) entspricht, wobei der Typ 
Objekt (100) folgende Merkmale aufweist: 

- eine eindeutige Bezeichnung (2) der Identitat des Objekts 
(100) zur absoluten Ref erenzierung des Objekts (100), 

- einen logischen Namen (3) zur Benennung des Objekts (100) 
und 

- mindestens eine Verknupfung (6) mit einem zweiten Element, 
welches einem Typ Feature (20) entspricht, wobei der Typ 
Feature (20) folgende Merkmale aufweist: 

- einen im Bezug auf das jeweilige verknupfte Objekt (100) 
eindeutigen Namen (21) und 

- die Moglichkeit der Verknupfung mit weiteren Elementen 
vom Typ Objekt (100), mit weiteren Elementen vom Typ 
Feature (20) und mit Daten (30, 40, 50) . 

2. System nach Anspruch 1, 

dadurch gekennzeichnet, 
dass der Typ Objekt (100) als weitere Merkmale eine 
Kennzeichnung des Objektstyps (5) und eine Kennzeichnung 
einer Version (4) des Objekts (100) aufweist. 

3. System nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

dass die durch ein Element vom Typ Feature (20) verknupften 
Elemente eine logisch zusammengehorige Teilmenge aller 
Elemente eines Objekts (100) bilden. 

4. System nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

dass die Elemente des Objekts (100) durch Referenzen (60) 
verknupft sind. 



200216717 




15 

5. System nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 
dass das Objektmodell (10) durch eine erweiterbare 
Kennzeichnungssprache beschrieben wird. 

6. Verfahren zur .Strukturierung, Speicherung und Verarbeitung 
von Daten gemaii einem generischen Objektmodell (10), wobei 
das Objektmodell (10) mindestens ein erstes Element aufweist, 
welches einem Typ Objekt (100) entspricht, wobei der Typ 
Objekt (100) folgende Merkmale atifweist: 

- eine eindeutige Bezeichnung (2) der Identitat des Objekts 
(100) zur absoluten Ref erenzierung t des Objekts (100), 

- einen logischen Namen (3) zur Benennung des Objekts (100) 
und 

mindestens eine Verkniipfung (6) mit einem zweiten Element, 
welches einem Typ Feature (20) entspricht, wobei der Typ 
Feature (20) folgende Merkmale aufweist: 

- einen im Bezug auf das jeweilige verknupfte Objekt (100) 
eindeutigen Namen (21) und 

- die Moglichkeit der Verkniipfung mit weiteren Elementen 
vom Typ Objekt (100), mit weiteren Elementen vom Typ 
Feature (20) und mit Daten (30, 40, 50) . 

7. Verwendung eines Systems bzw. eines Verfahrens nach einem 
der vorhergehenden Anspruche zum Engineering (220) eines 
Automatisierungssystems (230) . 
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Zusammenf assung 

Strukturierung, Speicherung und Verarbeitung von Daten gemaft 
einem generischen Objektmodell 

Die Erfindung betrifft ein System sowie ein Verfahren zur 
Strukturierung, Speicherung und Verarbeitung -.von Daten. Der 
Datenaustausch zwischen verschiedenen Sof tware-Applikationen 
wird vereinfacht durch die Strukturierung, Speicherung und 
Verarbeitung gemaJi einem generischen Objektmodell (10) , wobei 
das Objektmodell (10) mindestens ein erstes Element aufweist, 
welches einem Typ Objekt (100) entspricht, wobei der Typ 
Objekt (100) folgende Merkmale aufweist: 

- eine eindeutige Bezeichnung (2) der Identitat des Objekts 
(100) zur absoluten Ref erenzierung des Objekts (100), 

- einen logischen Namen (3) zur Benennung des Objekts (100) 
und 

- mindestens eine Verknupfung (6) mit einem zweiten Element, 
welches einem Typ Feature (20) entspricht, wobei der Typ 
Feature (20) folgende Merkmale aufweist: 

- einen im Bezug auf das jeweilige verknupfte Objekt (100) 
eindeutigen Namen (21) und 

- die Moglichkeit der Verknupfung mit weiteren Elementen 
vom Typ Objekt (100), mit weiteren Elementen vom Typ 
Feature (20) und mit Daten (30, 40, 50) . 
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